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DETAILED ACTION 

1 . This office action is in response to application 10/585,934 filed on 07/13/2006. 
Claims 1-9 are pending in the application. 

Specification 

2. This application does not contain an abstract of the disclosure as required by 
37 CFR 1 .72(b). An abstract on a separate sheet is required. 

3. The title of the invention is not descriptive. A new title is required that is 
clearly indicative of the invention to which the claims are directed. 

The following title is suggested: method for design and verification of safety 
critical systems. 

Claim Rejections - 35 USC § 101 

35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, macliine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

4. Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non-statutory subject matter. A method that recites purely mental steps is 
descriptive material and is nor statutory if not claimed as method (1 ) tied to another 
statutory class (such as a particular apparatus) or (2) transform underlying subject 
matter (such as an article or materials) to a different state or thing (See in re Bilski, 545 
F.3d 943, 88 USPQ2d 1385 (Fed. Cir. 2008)). 
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5. Claim 1 is also rejected under 35 U.S.C. 112, first paragraph. Specifically, 
since the claimed invention is not supported by either a claims or Specification asserted 
utility or a well established utility for the reasons set forth above, one skilled in the art 
clearly would not know how to use the claimed invention. 

6. Claim 8 is rejected under 35 U.S.C. 101 because the claimed Invention is 
directed to non-statutory subject matter. A computer program product comprising a 
computer readable medium is descriptive material and is nor statutory (See MPEP 
21 06.01 ) if not claimed as a computer-readable storage device for storing 
computer-executable software/instructions/program because the computer program 
product comprising a computer readable medium is non-statutory subject matter per se 
(for example, a carrier wave). 

7. Claim 8 is also rejected under 35 U.S.C. 112, first paragraph. Specifically, 
since the claimed Invention Is not supported by either a claims or specification asserted 
utility or a well established utility for the reasons set forth above, one skilled In the art 
clearly would not know how to use the claimed invention. 

Claim Rejections - 35 USC §112 
The following is a quotation of the second paragraph of 35 U.S.C. 1 1 2: 

The specification sliall conclude witli one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

8. Claim 9 is objected to under 37 CFR 1 .75(c) as being In improper form 
because a multiple dependent claim cannot depend from any other multiple dependent 
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claim. See MPEP § 608.01 (n). Accordingly, the claim has not been further treated on 
the merits. 

Also a tool as in method/process claims 1 to 7 programmed/made by a program 
of claim 8 is improper 

9. Regarding claims 1 , 2, 7 and 8 the phrases "for example" "e.g." render the 
claims Indefinite because it is unclear whether the limitation(s) following the phrase are 
part of the claimed invention. See MPEP § 2173.05(d). 

Claim Objections 

10. Claims1-9 are objected to because of the following informalities: 

The numbering of claims is not in accordance with 37 CFR 1 .126 which requires 
the original numbering of the claims to be preserved throughout the prosecution. When 
claims are canceled, the remaining claims must not be renumbered. When new claims 
are presented, they must be numbered consecutively beginning with the number next 
following the highest numbered claims previously presented (whether entered or not). 

Misnumbered claim1-9 must be renumbered. 

1 1 . Claim 3 is objected to because of the following informalities: 
Replace "state chars" with - state charts ~. 

12. In claims 1 and 8 Applicant must clarify what is "where possible" (what will be 
"where not possible"?). 

13. Claim 9 is objected to because of the following informalities: 
Replace "to implements" with - to implement -. 
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Appropriate correction is required. 

Claim Rejections - 35 USC § 102 

The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described In a printed publication In this or a foreign country or In public 
use or on sale In this country, more than one year prior to the date of application for patent In the United 
States. 

14. Claims 1-6, 8-9 are rejected under 35 U.S.C. 102(b) as being unpatentable 
by Torres-Pomales (Software Fault Tolerance: A Tutorial; Technical Report: NASA- 
2000-tm210616; Year of Publication: 2000; pages 1-55). 

15. As to claims 1 and 8 Torres-Pomales discloses: 

Claim 1 A method of producing a system architecture comprising a 
plurality of electrical devices connected to each other, said system preferably 
comprising a fault tolerant system (page 2. paragraph 5; page 34, last paragraph; 
page 35, paragraph 1; Fig.1), the method including: 

a) identifying a set of undesirable events and ascribing to each of said 
undesirable events an indicator of their severity (A system safety design begins by 
performing modeling and analysis to Identify and categorize potential hazards . This Is 
followed by the use of analysis techniques to assign a level of severity of occurrence to 
the identified hazards - page 8, paragraph 4); 

b) associating where possible each said undesirable event with one or 
more actuators of said system architecture (As best understood, upon detection of a 
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computer or actuator failure/associating where possible each said undesirable event , 
control is passed to another computer based on a predetermined hand over sequence - 
page 37, last paragraph); 

c) developing a functional specification of an initial architecture proposed 
for implementation of said system architecture, said functional specification of 
said initial architecture (The initial design of this flight control computer was a four by 
three configuration including hardware and software/ functional specification 
dissimilarity in all the channels. Software diversity was to be achieved through the use 
of different programming languages targeting different lane processors . The final and 
current implementation uses only one programming language with the executable code 
being generated by three different compilers still targeting dissimilar lane processors. 
The lane processors are dissimilar because they are the single most complex hardware 
devices, and thus there is a perceived risk of design faults associated with their use - 
page 36, last paragraph) including dataflow for and between components thereof, 
said components comprising for example sensors or actuators (page 4, paragraph 
2; page 35, Fig. 19); 

d) refining on said functional specification the fault tolerance requirements 
associated with the severity of each said undesirable event and issuing refined 
fault tolerance requirements of said functional specification(Figure 2 presents the 

Prototyping Process Model. This process model is appropriate for projects where the 
requirements are incompletely specified or when the developers are unsure whether a 
proposed design solution is adequate. The process begins with a reguirements capture 
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activity , followed by a quick design and build of a prototype or mocl<-up of tlie product. 
After analyzing the prototype, further refinements to tlie requirements are generated 
and the process begins again . This cycle activity not only helps develop the 
requirements, but it also helps the developers better understand the problem - page 3, 
paragraph 2); 

e) producing replicates in said functional specification together with 
attached indicators of independence of said replicates, said indicators reflecting 
said refined fault tolerance requirements (Multi-version fault tolerance is based on 

the use of two or more versions (or "variants") of a piece of software, executed either in 
sequence or in parallel. The versions are used as alternatives (with a separate means 
of error detection), in pairs (to implement detection by replication checks) or in larger 
groups (to enable masking through voting). The rationale for the use of multiple versions 
is the expectation that components built differently (i.e., different designers, different 
algorithms, different design tools, etc) should fail differently. Therefore, if one version 
fails on a particular input, at least one of the alternate versions should be able to provide 
an appropriate output - page 10, paragraphs 2-6; page 11; page 12, paragraph 1; page 
17, paragraphs 3-4; page 18; pages 19-21); 

f) defining a hardware structure for said system architecture, e.g. a series 
of electronic control units connected to each other by networks (Fig. 19); 

g) mapping of said functional specification onto said hardware structure 
(The integration process is the phase of development when the source code is linked 
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and transformed into tlie executable object code to be loaded on the target computer 
hardware - page 4, paragraph 4); and 

h) verifying automatically that said indicators of independence are 
preserved during mapping (The supporting processes are three: verification, 
configuration management, and quality assurance. The purpose of the verification 
process is to search and report errors in the software requirements, design, source 
code, and integration. Verification is composed of three types of activities: reviews, 
analysis and testing - page 4, last paragraph, page 5); 

Claim 8 A computer program product comprising a computer readable 
medium having thereon computer program code means, when said program is 
loaded, to make the computer execute procedure to design and verify system 
architecture (page 27, paragraphs 2-3), said procedure comprising: 

a) identifying a set of undesirable events and ascribing to each of said 
undesirable events an indicator of their severity (A system safety design begins by 
performing modeling and analysis to identify and categorize potential hazards . This is 
followed by the use of analysis techniques to assign a level of severity of occurrence to 
the identified hazards - page 8, paragraph 4); 

b) associating where possible each said undesirable event with one or 
more actuators of said system architecture (As best understood, upon detection of a 
computer or actuator failure/associating where possible each said undesirable event , 
control is passed to another computer based on a predetermined hand over sequence - 
page 37, last paragraph); 
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c) developing a functional specification of an initial architecture proposed 
for implementation of said system architecture, said functional specification of 
said initial architecture (The initial design of this flight control computer was a four by 
three configuration including hardware and software/ functional specification 

dissimilarity in all the channels. Software diversity was to be achieved through the use 
of different programming languages targeting different lane processors . The final and 
current implementation uses only one programming language with the executable code 
being generated by three different compilers still targeting dissimilar lane processors. 
The lane processors are dissimilar because they are the single most complex hardware 
devices, and thus there is a perceived risk of design faults associated with their use - 
page 36, last paragraph) including dataflow for and between components thereof, 
said components comprising for example sensors or actuators (page 4, paragraph 
2; page 35, Fig. 19); 

d) refining on said functional specification the fault tolerance requirements 
associated with the severity of each said undesirable event and issuing refined 
fault tolerance requirements of said functional specification(Figure 2 presents the 
Prototyping Process Model. This process model is appropriate for projects where the 
requirements are incompletely specified or when the developers are unsure whether a 
proposed design solution is adequate. The process begins with a reouirements capture 
activity , followed by a quick design and build of a prototype or mock-up of the product. 
After analyzing the prototype, further refinements to the reouirements are generated 
and the process begins again . This cycle activity not only helps develop the 



Application/Control Number: 10/585,934 Page 10 

Art Unit: 2825 

requirements, but it also helps the developers better understand the problem - page 3, 
paragraph 2); 

e) producing replicates in said functional specification together with 
attached indicators of independence of said replicates, said indicators reflecting 

said refined fault tolerance requirements (Multi-version fault tolerance is based on 
the use of two or more versions (or "variants") of a piece of software, executed either in 
sequence or in parallel. The versions are used as alternatives (with a separate means 
of error detection), in pairs (to implement detection by replication checks) or in larger 
groups (to enable masking through voting). The rationale for the use of multiple versions 
is the expectation that components built differently (i.e., different designers, different 
algorithms, different design tools, etc) should fail differently. Therefore, if one version 
fails on a particular input, at least one of the alternate versions should be able to provide 
an appropriate output - page 10, paragraphs 2-6; page 11; page 12, paragraph 1; page 
17, paragraphs 3-4; page 18; pages 19-21); 

f) defining a hardware structure for said system architecture, e.g. a series 
of electronic control units connected to each other by networks (Fig. 19); 

g) mapping of said functional specification onto said hardware structure 
(The integration process is the phase of development when the source code is linked 
and transformed into the executable object code to be loaded on the target computer 
hardware - page 4, paragraph 4); and 

h) verifying automatically that said indicators of independence are 
preserved during mapping (The supporting processes are three: verification. 
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configuration management, and quality assurance. The purpose of tlie verification 
process is to search and report errors in the software requirements, design, source 
code, and integration. Verification is composed of three types of activities: reviews, 
analysis and testing - page 4, last paragraph; page 5). 

16. As to claims 2-6 and 9 Torres-Pomales recites: 

Claim 2 A method for defining a series of modes of operation, e.g. nominal 
and limp-home/degraded modes (page 17, last paragraph); 

Claim 3 A method that includes specifying said series of modes in the form 
of one or more state charts (page 12, last paragraph; page 13; page 14, paragraph 1); 

Claim 4 A method including mapping geometrically hardware components 
and/or wiring and then verifying automatically that said indicators of 
independence are preserved by said geometrical mapping (page 4, last paragraph; 
page 5); 

Claim 5 A method including specifying severity in the form of probability of 
failure per unit of time (page 7, paragraphs 2-4; page 5); 

Claim 6 A method according to any preceding claim including outputting a 
set of data for manufacturing said system architecture (page 26, paragraph 3; page 

29, paragraph 1); 

Claim 9 A design tool adapted for the design and verification of a system 
architecture have been programmed using the computer program product 
according to claim 8 (page 3, paragraph 2; page 4, paragraph 2; page 4, paragraph 4; 
page 4, last paragraph; page 5; page 8, paragraph 4; page 10, paragraphs 2-6; page 1 1 ; 
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page 12, paragraph 1; page 17, paragraphs 3-4; page 18; pages 19-21; page 27, 
paragraphs 2-3; page 35; page 36, last paragraph; page 37, last paragraph; Fig. 19). 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this 
title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a 
whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said 
subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. 

17. Claim 7 is rejected under 35 U.S.C. 103(a) as being unpatentable by Torres- 
Pomales in view of Ivarez-Troncoso et al. (U.S. Patent 7,076,350). 

With respect to claim 7 Torres-Pomales teaches the features above but lacks a 
method, wherein a system architecture comprises an architecture for a safety control 
circuitry of a brake system in a vehicle. 

18. As to claim 7 Ivarez-Troncoso recites: 

Claim 7 A method, wherein said architecture comprises an architecture for 
a vehicle, such as safety control circuitry for a brake system (electrical energy, 
power, and load management (EM) system controls power generation, storage, and 
consumption according to different operational states of a vehicle. An EM system 
typically has the capability of disengaging lower priority loads during specific conditions 
in order to maintain sufficient power to higher priority (e.g., safety-related) loads). 
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Electrical system parameters that are monitored and controlled include break system of 
the vehicle - col.2, lines 34-67; col.3, lines 1-19). 

It would have been obvious to a person of ordinary skills in the art at the time the 
invention was made to improve Torres-Pomales' invention by implementing the method, 
wherein a system architecture comprises an architecture for a safety control circuitry of 
a brake system In a vehicle by providing an energy management control system for 
managing events in an electrical system based on forecasted states, thereby avoiding 
degraded electrical system performance without excessive processing requirements 
(col.1, lines 49-64). 



Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to NAUM B. LEVIN whose telephone number is (571)272- 
1898. The examiner can normally be reached on M-F (8:00-4:30). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor. Jack Chiang can be reached on 571-272-7483. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



/Naum Levin/ 
Examiner 
Art Unit 2825 



